Not Applicable.
Not Applicable.
Copyright 1999 The Santa Cruz Operation, Inc. A portion of the disclosure of this patent document contains materials that are subject to copyright protection. The owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all rights, copyright rights whatsoever.
1. Field of the Invention
The present invention relates to networked data processing environments using a client/server architecture, and, in particular, to client-server systems where there exist one or more clients of varying capability connected via network connections of varying bandwidth and latentcy to one or more servers providing application program services or database services to the connected clients.
2. Background Information
Until the 1980s the computer network typically was used as a means of connecting to a large mainframe environment using dedicated hardware terminals and proprietary protocols. Next UNIX servers grew in usage and with it came standardization of the networking protocols, in particular TCP/IP (Transmission Control Protocol/Internet Protocol). Simultaneously, there was a shift in the computing paradigm towards client/server architectures. This allowed the processing power to be distributed over the network and not be limited to servers which could not scale to meet the growing number of users and their increasing demands. This lead to the need for clients to become more intelligent and powerful. Significant desktop clients came into use: Microsoft Windows. Each iteration of this operating system brought about more functionality requiring more powerful desktop clients. More and more software had to be installed on these clients leading to what is termed xe2x80x9cfat clientsxe2x80x9d and each client required individual configuration. People began to find that the amount of time and money required to maintain these powerful clients was increasing.
High availability networks together with hardware and software needed to support such networks have become the norm. In these environments there is not a homogeneous structure of one type of server and one type of client, but a variety of such devices. Within a network there is a wide variety or servers and clients. Upgrades and new applications for this diverse mix of clients usually require that each client be individually upgraded. Also each user has specific needs on the desktop client: configuration, security, access control, mobility. The information services department provides this by administering each client separately. If remote offices are involved, costs to do this increase significantly. Performance in this heterogeneous client network must also be maintained. Slow performance takes up time and money. Networks vary in bandwidth, e.g. modem links, ATMS, Frame Relays, etc.
The World Wide Web (the xe2x80x9cWebxe2x80x9d) has come to the forefront in the current era of the Internet/Intranet and networks have become an integral part of day to day work. Modem speeds double every year and 100 Mbit/sec Local Area Networks have arrived. The Web is now a well-accepted medium for publishing information, in the form of text and graphics (including sound and video). Web programming languages such as Java, JavaScript, and CGI have now extended the Web to applications. This is fine for new applications but existing applications also need a route into this world.
Existing applications have either had a character-based or windows-based user interface. Now such applications need a web user interface. The web user interface provides a presentation layer to the user of the application. It must provide an input/output method for the user to interact with the application. There are a number of ways to do this including: (1) HTML (HyperText Markup Language) replacement of the current user interface; (2) Non-Java plug-ins; and (3) Java-based emulation. The first solution involves rewriting the application. The second involves installing more software on the clients leading to xe2x80x9cfat clients.xe2x80x9d The third is preferred.
A large number of vendors offer a character or graphical emulation package that runs on desktop clients such as Windows, UNIX, etc. These emulators could be rewritten in Java and such Java emulator will run on just about any client. However, this approach leads to fat Java clients. For performance reasons, users will not want to wait for large Java applets to download. These Java applets will grow in size, as users demand more and more functionality. Storing these Java applets locally solves the performance problem but leads to fat clients. If state information is stored on the client leading each client to have its own particular configuration parameters, the problem of fat clients is further exacerbated and each client is being managed individually rather than from a central place on the server.
Web browsers have an API (Application Programmers Interface) enabling software developers to provide helper applications that allow users to run applications or view unsupported document types on their client platform. These are termed xe2x80x9cbrowser plug-ins.xe2x80x9d They are both platform-specific and browser-specific. For example, for two platforms (Windows and UNIX) and two browser types (Netscape and Microsoft), four different implementations of the plug-in would be needed. This type of solution is not cross platform and the majority of these plug-ins are proprietary (e.g., Microsoft ActiveX) locking users into vendor specific solutions.
Once the web display of an application is possible, the next step is to make it available to all users. A number of methods that could be used include: (1) local installation; (2) push technology; (3) on-demand access. Local installation involves an administrator installing the application or connectivity software on every single client. This is disadvantageous in that it makes the clients more difficult and costly to manage and leads to fat clients. Push technology involves storing all the files and data associated with users and applications on a server and transmitting them out via virtual channels on a network to clients. Where all storage is on the sever, users experience poor performance in waiting for applets and applications to execute, or downloads are cumbersome and in some cases unusable. Local storage of applications and state information is used to improve performanc. This approach starts off well by using a central server but when applications and any associated state are stored on the client, the fat client problem arises. With on-demand access as used in the present invention, user state, applications, connectivity software and the associated configuration data are stored on a server. Applets are downloaded on demand when the clients request an action, such as start up an application. All state information is kept on the server and can then be managed centrally rather than individually on each client. Keeping state information on the server also makes the client resilient. If the client connection is lost or the client itself is replaced, nothing is lost and no replication is needed.
Next the applications and data must be made available to selected users in a secure manner. For manageability, this is done centrally on a server and made available by the most common medium to all users, the Web. But this raises more questions:
What do web pages on that server have to contain?
What editor has to be used?
How do you make it available to selected users or groups of users?
Are there different web pages for different types of users?
Where does the user profile and application configuration reside?
Do users authenticate themselves every time they want to run applications?
How is the authentication done?
What if the user is already authenticated on the server and does not want to do again and again for each application?
What if all of this information is already available and duplication is not desired?
As the above list shows, providing a display mechanism via Java emulation is only a partial solution to web-based delivery of applications.
To achieve optimal performance on all networks is difficult. Protocols are designed with specific functions in mind, e.g., inter-process communication, graphics rendering, etc. Protocols are rarely designed with the goal of providing uniform performance over complex network routes that have different permutations of bandwidths. To choose the right protocol a number of assumptions could be made. For a high bandwidth network, such as a fast LAN with low latency, the X protocol works well but is unusable over a slow modem link. For a low bandwidth network, such as a slow WAN or modem connection, compression can be used to optimize performance. The ICA protocol of Citrix Systems, Inc. works well over a slow modem connection but is inefficient on a fast LAN connection.
It would be advantageous to be able to deliver upgrades to existing applications or roll out new applications to diverse clients; to be able to centralize the administration of clients and their applications; to be able to balance loads in a heterogeneous client server network and to provide high security and manage sessions across heterogeneous servers and services.
The inventive universal application server, also termed an application broker, is added in a nondisruptive manner to an existing computer network environment forming a second server tier intermediate the application servers tier on a third tier and the client devices on a first tier. The system provides the following elements:
a shared database that is used to describe the location of the application programs, the application servers, the users of the system and a description of which users are provided with access to which application programs;
a set of protocol engines processes which support industry standard display protocols (X11, telnet, VT220, etc.) which form the protocols as used by the application programs;
a set of display engines processes which are designed to operate within the various client device environments and which communicate with the PE to provide presentation and user interaction services with the users of the client devices;
a set of delivery servers which can be used to deliver the display engines to the client devices on demand; and
a set of management enginesxe2x80x94a data store engine, a status engine, a session manager engine, an administrative engine that allow manipulation of the shared database and control of the operation of the system.
Once the application broker has been installed into the existing client server environment it operates in the following manner. Management processes define and maintain the shared database. This consists of making entries for each user of the system for each application server and for each application program. Users connect to the application broker from their client devices and are authenticated against the database. Display engine components are automatically downloaded to the client device, and are used to present the user with a webtop (visual menu) of applications that are available for execution. The contents of the webtop are specific to the user and are constructed dynamically from the database. The user chooses which applications to run. This information is passed from the display engine running on the client device to the universal application server The universal application server, using information stored in the database determines the location of the application program and communicates using industry standard protocols with the appropriate application server. This communication causes the launch of an instance of the application program to take place. The application program launches and is instructed to perform user interaction over a standard protocol by the universal application server.
The application broker also arranges to create an instance of the appropriate protocol engine to handle the specific protocol used for a number of applications, such as X-windows applications. It also downloads a suitable display engine to the client device to interact with the user. The protocol engine takes output requests from the application program and converts them into a form that is suitable for use by the downloaded display engine. This information is then forwarded to the display engine where it then converts the information into a form suitable for display within the client device environment. The user interactions with the display engine and the result of these actions (typing, mouse manipulation etc.) are transmitted to the protocol engine. The protocol engine converts these user inputs into the standard protocol used and passes them to the application program.
As set forth in the copending application referenced above the protocol engines and display engine processes transmit to and display on the display device of the client device, display requests of the requested application service which are not supported by the client device. The protocol engine is initialized with parameters of the client device comprising display operations supported by the client device, the relative cost of each supported operation and a local performance factor and parameters of the connection from the server to the display engine comprising bandwidth and latency. The protocol engine maintains a first queue for retaining pending display requests and a second queue for retaining transmitted display requests of the requested application service for display on the client device. Each request has a corresponding relative cost and request time determined by the relative cost and the local performance factor. The protocol engine also maintains a total request time for all requests in both queues and maintains a total network time for all requests in the second queue.
While the total request time is less than a predetermined first value, the protocol engine accepts new pending requests from the application service that are to be displayed on the client device. The protocol engine executes the new pending display request to create an image to be displayed on the client device, saves the resulting image to memory and determines for the image its relative cost and its corresponding request time based the local performance factor received from the display engine. The protocol engine also converts the new pending display request from the application service into a sequence of converted requests that are supported by the client device, places the sequence of converted requests in the first queue, determines for each converted display request in the sequence its relative cost and its corresponding request time based on the local performance factor, and increments the total request time by the request time of each added request. Further while the total network time is less than a predetermined second value optimizing the first queue using a merge optimization occurs when the request times of the pending requests in the first queue exceed a predetermined third value. The total request time is updated based on the results of the merge optimization. Next a pending request is read from the first queue and labeled with a first sequence identifier. Each read request is then encoded for transmission to the display engine over a network connection. A copy of the optimized request is placed into the second queue and the total network time is incremented by the request time for the newly added request. The encoded display request is transmitted to the display engine. The display engine unencodes the received converted display request and displays it on the client device. Next it generates a second sequence identifier corresponding to first sequence identifier of the displayed request; and periodically transmits to the protocol engine the second sequence identifier of the last received display request displayed on the client device.
Upon receipt of the second sequence identifier, the protocol engine further comprises the steps of:
deleting from the second queue the display request whose first sequence identifier is the same as the second sequence identifier and all pending displayed requests in the second queue having first sequence identifiers that are prior to such second sequence identifier; and
decrementing from the total request time and from the total network time the request time values of each of the deleted display requests.
The application broker using the information contained in the data store regarding the application programs and the application servers used to run them is able to keep track of which third tier server is actually running the application program. The number of all applications running on each application server is tracked. At launch time of the application program, the application broker chooses the application server from the list associated with the application that currently has the lowest number of applications running on it. This selection process provides a load balancing mechanism for the application servers.